The field of network computers is presently in its infancy. However, it is expected to evolve rapidly, especially in the corporate environment, for a number of reasons. The expectation is that as companies and possibly individual users reach hardware and software upgrade points, it will be more efficient and less expensive to move to this new field, rather than upgrade in the traditional way with disk equipped computers and locally stored and administered software applications. For example, in the corporate environment, a user can be connected to a corporate intranet, using, for example, the TCP/IP and HTTP protocols of the Internet, and download software applications as they are needed directly from a network server to the desktop computer. An application is executed on the desktop in the traditional manner by the user to perform useful work. An advantage of this configuration is that network computers are substantially less expensive than traditional disk equipped computers. It might also cost less to purchase the required number of software licenses for users, rather than purchase individual copies of software for each user. Certainly, the software administration problems that attend large numbers of corporate users will be substantially reduced. At the present time, each user of a disk equipped computer or workstation often is effectively his or her own system administrator, a role that often consumes excessive resources due to lack of expertise. It is expected to be a great advantage to eliminate this problem by effectively offloading the problem to a small number of server administration experts, rather than having many users struggle with the problems of software installation, upgrades and computer administration.
As mentioned above, this vision of the future of personal computing is presently in its infancy. As a result, there are presently many problems and deficiencies with existing systems.
Typically, in network computer systems, an administrator creates user profiles that are stored on a network server. The profiles may contain different types of information, such as user desktop preferences and user permissions for access to different software applications that might reside on the server. When a user logs onto the system, the user identifies him or herself to the server, the server locates the profile for the user and transmits it to the user computer where it is used to configure the computer and generate a desktop. The desktop might include a number of icons representing applications to which the user presumably has access. The profile likely also contains other attributes of the computer and desktop, such as for example, the background color of the desktop, or character fonts and point sizes used on the desktop, or data file search paths, etc. that are unique to the user. The profiles may be user modifiable or non-modifiable.
In an environment in which users can modify their own profiles, a modified profile is uploaded back to the server at log-off time, where it is stored for retrieval the next time the user logs-on. In some prior art systems, to the best of our knowledge, the users can generate on their desktops any configuration of application icons they wish, whether or not they exist on the server, and whether or not a user actually has access permission to an application on the server. The Lotus Workplace Desktop (previously called Kona Desktop) system is an example of this type of operation. In other systems, the server presents a list to the user of all applications that the server has, from which the user can pick. In this case, there is no guarantee that the user actually has access permission to an application that is selected from the list for inclusion on the desktop. The Sun Hot Java Views system is an example of this type of system. In other words, the prior art systems do not correlate between what the user can configure for the set of desktop application icons and applications to which the user actually has permission access. In such a case, when the user clicks on a icon to execute an application, an error message may occur (such as an unauthorized access message) if access permission is not present, or in a worse case, the user's computer may crash.
Another limitation with existing art is that a flat data structure is used to model users, user groups, terminals and groups of terminals. Modeled after a common scheme for managing user access to computer resources, known network computer implementations (e.g., Lotus Administration Facility for Desktops, Microsoft Windows NT Profiles and Policies, and Sun Hot Java Views) implement a flat "groups" structure on the server for managing software preferences (or attributes) in various contexts. A "context", as used here, refers to an individual user, user group, terminal, or terminal group. Any grouping structure for managing software preferences on the server allows an administrator to define preference attributes for different groups of users as well as for individual users. However, flat systems are inflexible in many environments, especially in environments having large numbers of users. It is desirable to provide an administrative tool supporting the organization of preference information into a hierarchical structure.
Another limitation with existing systems is that they are limited in the ways that administrators and users have to perform user configuration of workstation desktops. For example, administrators are presently required to configure user preferences using configuration programs that are separate from, but associated with, a user application. It is desirable to allow vendors to provide only a single application. To require only an end user application from a vendor necessitates that the central management facility be able to execute the end user application in a context of a user or user group. The prior art does not allow this administrative flexibility of operation. In other words, in the prior art, to the best of our knowledge, an administrator does not have the ability to run a user application in the context of a user to set preferences for that user and application. Further, in the art, an administrator cannot run a user application to set preferences in the context of a group of users.
Still another limitation in the prior art known to the inventors is the manner in which the prior art partitions server permanent storage space to guarantee that a unique space is reserved for storing user preferences related to the different applications on the server. To the knowledge of the inventors, the problem of preventing collisions in the storage of preference information for different applications in object-oriented systems, in which an object can be queried for its fully qualified class name which uniquely identifies and differentiates it from other classes, is solved by having a first central authority assign a unique designation that applies to a vendor and by then having a second authority at the vendor assign a second designation relative to the first designation for each vendor application. For example, vendor A might be assigned the designation vendorA by the first authority and that designation is guaranteed to be unique within the architecture for which the first authority is acting. The second authority at vendor A then assigns the second designation for each of its applications within that architecture. For example, one of vendor A's applications might be designated-vendorA.App1; another might be designated vendorA.App2. The art maps the unique designation for each application in a system to a location in permanent storage of the system to guarantee that preference data for the different applications do not collide in storage. An application, when running, informs the network computer server of its unique storage location and it is the responsibility of the server to partition an area at the starting location according to a context (user, user group, terminal or terminal group) for storing preference information so as not to collide with preference information in a different context. Clearly, this manner of administering storage space is awkward and undesirable. It is desirable to devise a method to automatically generate unique storage locations for storing preference information for the afore mentioned object-oriented applications, without resorting to the requirement of having central authorities assign unique designations for the purpose of preventing collisions in the storage of preference information and without coding storage location information into an application.
Still another limitation in the art lies in the lack of any provision to migrate existing applications and hardware into the new environment of the centrally managed network computing world without requiring changes to the existing hardware and applications. Existing hardware, a terminal for example, in a networked environment, gets its configuration information at boot-up time from a file in a specific format located on a server. The terminal is programmed to know how to access its configuration file. The terminal uses a unique identifier to access the file from the server. The unique identifier is often the media access control (MAC) address of the terminal. However, in a new centrally managed environment involving protocols and API's that are different from that to which the terminal is designed, the terminal cannot access preference information in the new environment, the terminal can only access its configuration file in the way for which it is designed. This is a serious problem, because there are many such existing devices in use. The inability to use them in new systems impedes substantially the incentives for users to migrate to the new systems.
Still another limitation in the prior art concerns the interface between an administrator and the configuration management system. When configuring software within an administration facility to configure preference information for various users and user groups, and terminals and terminal groups, the administration software launches in the context (user, user group, terminal or terminal group) set by the Administrator who is running the facility. When the Administrator changes the context that the application is running under, the application needs to be relaunched to load configuration information for the new context. The process of relaunching software each time a context is changed is time consuming and inconvenient for an administrator, especially in systems with many users. In such systems, it is expected that an administrator will change contexts many times while configuring an application.
The system described herein provides a common repository for configuration information for users and applets in a client-server environment. This is referred to as client profile management. The system allows users to roam, that is, to log-in from any computer in the system at any time and have it configured automatically at run time according to the preferences stored for the user at the server. The preferred embodiment is a Java (Java is a Trademark of Sun, Inc.) based system and the client computers use a web browser interface arranged to execute Java applications. Thus, in the preferred embodiment, user applets and the desktop applet are assumed to be Java applets. However, it is not intended to limit the invention to a Java environment. Preferences for the locally stored applications might be stored locally in the traditional manner, while preferences for the server-based applets might be handled in the way described herein.
The invention provides a means whereby vendors of existing hardware and soft ware can integrate the hardware or software into the environment of a centrally managed network computing system, without having to retrofit the hardware with new firmware or without having to redesign the existing software. The system provides an export service that allows a system administrator to generate configuration files in the format that the existing hardware or software expects and to store the files at the server in a way that the existing hardware or software can access the files in the manner for which it is designed. To take advantage of the export service, a hardware vendor, for example a vendor of an existing terminal, creates a special configuration application and an export agent module. The special configuration application is executed at a system administrator station and allows the administrator to create configuration information for the hardware. The export agent module resides on the server. When the vendor supplied configuration application is executed by an administrator and a request is made to save the configuration information generated by the configuration application on the server, the save call to the server includes an export tag parameter that tells the server to invoke the specified export agent. The export agent takes the configuration information from the configuration application and modifies its format to that required by the hardware. In addition, the context being configured is passed to the export agent. The context includes information unique to the particular instance of hardware that is being configured, typically but not necessarily the media access control address of the hardware, that provides information to the export agent indicating where to store a file or files that contain the modified configuration so that it does not collide with similar information for other instances of the hardware and can be accessed directly by the piece of hardware from the server in the way that it is designed to do. Existing software applications can also be retrofitted into the system without redesign, if desired, in the same way.
In the preferred embodiment, the system comprising a network which interconnects interconnecting a server and a plurality of user stations. The server stores a plurality of end user applications for downloading to user stations and further stores configuration preferences for the end user applications in the context of different groups and subgroups of users. A profile manager is provided at an administrators station. The profile manager is arranged to execute a configuration application for the non-native stations or applications, whereby the administrator can specify configuration preferences for non-native stations or applications in the context of different groups and subgroups of system users. An export agent corresponding to the configuration application is also provided at the server. The export agent is invoked when a request is made by the profile manager to store preference information on the server for the non-native terminal or application. The export agent reformats the preference information into a format compatible with the non-native terminal or application, and it stores the reformatted information in a location on the server which is known to the non-native terminal or application for direct access by the non-native terminal or application.